AMD製CPUを搭載した「T3a」インスタンスの 性能をLinuxカーネルのビルド時間で比較してみた
はじめに
AWSチームのすずきです。
2019/4/24、AMDのEPYC サーバープロセッサーを搭載した「T3a」ファミリーのインスタンスが、バージニア、オレゴン、アイルランド、オハイオ、シンガポールリージョンで利用可能になりました。
今回、LinuxカーネルのSRPMパッケージのリビルドの所要時間を測定、「T3a」と既存インスタンスとの性能を比較する機会がありましたので、紹介させていただきます。
T3aスペック一覧
Instance Name | vCPUs | RAM | EBS-Optimized Bandwidth | Network Bandwidth | 料金(US$) |
---|---|---|---|---|---|
t3a.nano | 2 | 0.5 GiB | Up to 1.5 Gbps | Up to 5 Gbps | 0.0052 |
t3a.micro | 2 | 1 GiB | Up to 1.5 Gbps | Up to 5 Gbps | 0.0104 |
t3a.small | 2 | 2 GiB | Up to 1.5 Gbps | Up to 5 Gbps | 0.0208 |
t3a.medium | 2 | 4 GiB | Up to 1.5 Gbps | Up to 5 Gbps | 0.0416 |
t3a.large | 2 | 8 GiB | Up to 2.1 Gbps | Up to 5 Gbps | 0.0832 |
t3a.xlarge | 4 | 16 GiB | Up to 2.1 Gbps | Up to 5 Gbps | 0.1664 |
t3a.2xlarge | 8 | 32 GiB | Up to 2.1 Gbps | Up to 5 Gbps | 0.3328 |
※料金は米国リージョン、Unix/Linux 1時間単価
CPU情報
- AmazonLinux2の「lscpu」コマンドを利用してCPU情報を確認しました。
- CPUモデルは「AMD EPYC 7571」、先行してリリースされていた「M5a」「R5a」と共通でした。
$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 2 Core(s) per socket: 1 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 23 Model: 1 Model name: AMD EPYC 7571 Stepping: 2 CPU MHz: 2199.650 BogoMIPS: 4399.30 Hypervisor vendor: KVM Virtualization type: full L1d cache: 32K L1i cache: 64K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 0,1 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch topoext vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save
T3a、T3 比較
比較方法
Amazon Linux2 ユーザデータを利用して、EC2インスタンスの起動時に Kernel SRPM パッケージのリビルドを実施。 t3a.large、t3.large のそれぞれの所要時間を測定しました。
環境
- AMI: Amazon Linux2 (amzn2-ami-hvm-2.0.20190313-x86_64-gp2 (ami-061392db613a6357b)
- インスタンス: t3a.large、t3.large
- リージョン: us-west-2c
- SRPMパッケージ: kernel-4.14.109-99.92.amzn2.src.rpm
UserData
#cloud-config repo_update: true repo_upgrade: all packages: - rpmdevtools - m4 - gcc - xmlto - asciidoc - openssl-devel - elfutils-devel - zlib-devel - binutils-devel - newt-devel - bison - audit-libs-devel - numactl-devel - pciutils-devel - pesign - hmaccalc - 'perl(ExtUtils::Embed)' runcmd: # rpmbuild - groupadd mock - useradd -G mock mockbuild - su -c "mkdir -p /tmp/$$; cd /tmp/$$; yumdownloader --source kernel.x86_64; ls -la; time rpmbuild --rebuild \`ls\` " mockbuild # s3copy - cat /var/log/cloud-init-output.log | gzip > /var/log/cloud-init-output.log.gz - aws s3 cp /var/log/cloud-init-output.log.gz s3://${S3Bucket}/`curl http://169.254.169.254/latest/meta-data/instance-type`/ - aws s3 sync /home/mockbuild/rpmbuild s3://${S3Bucket}/`curl http://169.254.169.254/latest/meta-data/instance-type`/ # shutdown - shutdown -h now
結果
- 実行時間(real)、「t3a」と「t3」はほぼ一致、10%単価の安い「T3a」が費用対効果に優れる結果となりました。
- ユーザCPU(user)の実行効率、「T3a」は「T3」に5%程度劣る模様ですが、システム時間(sys)は「T3a」が「T3」より優れ、相殺されている事が伺えました。
インスタンス | real (実時間) | user (ユーザ時間) | sys (システム時間) | 単価(オンデマンド1時間) | 実行時間課金額 |
---|---|---|---|---|---|
t3a.large | 40m38.760s | 66m34.276s | 5m50.582s | $0.075 | $0.051 |
t3.large | 40m39.620s | 63m55.735s | 7m21.634s | $0.084 | $0.057 |
他インスタンスとの比較
- 「M5」「M5a」「C5」「M4」「M3」の「Large」インスタンスでも、 同様の手順でKernel SRPM パッケージのリビルド時間を測定しました。
- 「T3」「T3a」のバースト課金は、Base性能を超過したCPU時間を (user + sys) - (real * 2コア * 0.3 (largeのBase性能)) との計算で求め、vCPU1時間単価0.05$を掛けて求めました。
- 「T3」「T3a」はT3無制限(unlimited)を無効とし、「large」のベース性能(30%)に抑えた状態での測定も実施しました。
結果
インスタンス | real | user | sys | 単価(オンデマンド1時間) | 課金額(実行時間+バースト) |
---|---|---|---|---|---|
c5.large | 36m9.620s | 56m30.844s | 6m55.215s | $0.085 | $0.051 |
m5.large | 38m41.216s | 61m32.127s | 7m4.547s | $0.096 | $0.062 |
m5a.large | 43m26.286s | 70m35.178s | 6m12.498s | $0.086 | $0.062 |
c4.large | 47m42.874s | 71m21.230s | 7m44.200s | $0.100 | $0.080 |
m4.large | 51m29.677s | 78m2.551s | 8m5.953s | $0.100 | $0.086 |
t3a.large | 40m38.760s | 66m34.276s | 5m50.582s | $0.075 | $0.088 ($0.051 + $0.037) |
t3.large | 40m39.620s | 63m55.735s | 7m21.634s | $0.084 | $0.094 ($0.057 + $0.037) |
m3.large | 59m1.889s | 93m3.751s | 10m33.206s | $0.133 | $0.131 |
t3a.large (base性能) | 123m59.920s | 66m44.836s | 5m58.416s | $0.075 | $0.155 |
t3.large (base性能) | 125m19.227s | 65m47.800s | 7m29.696s | $0.084 | $0.174 |
- 「T3a」「T3」インスタンス、CPU性能は「M5」に匹敵、「M4」の20%、「M3」の30% 良好な環境として利用できる事が確認できました。
- CPU負荷平均が「T3a」「T3」のベースライン性能に収まる利用の場合、「T3a」の費用対効果が優れる可能性があります。
- CPU性能を必要とするワークロードを旧世代のインスタンスで稼働させている場合、M3→最新世代のインスタンス採用により2倍の改善が図れる可能性があります。
まとめ
Intel製のCPUのインスタンスを搭載する「T3」と同等の性能、10%廉価な単価で利用できる「T3a」インスタンス、 単体でも費用対効果の良い利用が期待できます。
さらに、オートスケールやスポットフリートでは複数のインスタンスタイプを組み合わせた利用により在庫不足を回避する事が可能ですが、 従来「T2」を「T3」と組み合わせた場合、「T2」がボトルネックになりがちでした。
性能差の少ない「T3a」「T3」の組み合わせであれば、バランスのよい利用が期待できます。
また、過去にEC2インスタンスで利用されているCPUに深刻な脆弱性が報告され、システム影響を伴うメンテナンスが求められる事がありましたが、 採用するCPUに多様性をもたせる事で、影響範囲を抑えるといった効果も期待できると思われます。
2019年4月現在、東京リージョンでは「T3a」は未リリースですが、 AMDのEPYC サーバープロセッサーを搭載したインスタンスとして「M5a」「R5a」の利用が可能です。 費用対効果に優れたインスタンスとしてお試しください。